Corporate employees and customers need access to systems resources and applications in secure and reliable environments. The administration and control of access to such resources is made more challenging with the growing trend toward corporate employee and customer turnover, the use of temporary contract personnel as a core supplement to a corporation's workforce, the continuous installation of new applications, as well as updates to and the removal of existing applications from corporate networks. Security administration has become an increasingly more complex and expensive aspect of the management of large enterprise networks given these trends.
Role-based access control (“RBAC”) technologies and methods have evolved from the research and development efforts of the United States Department of Defense, as well as David Ferraiolo and Richard Kuhn, among others, in response to the growing challenge of security administration. Role-based access control has emerged as one of the accepted models for security administration in large, networked computing environments. RBAC technology is being developed and deployed in areas such as defense, health care, as well as banking and finance.
Role-based access control entails the categorization of computer system users into roles. A role is, for example, a construct that is created by a systems administrator according to, for example, the job functions performed by users within an organization. Computer system users can be assigned to roles on the basis of their particular job responsibilities and qualifications. Users are not assigned access permissions directly. Instead, roles are granted various permissions or access authorizations to data and/or systems resources based on the authority and responsibility conferred upon users that are assigned to these roles. Roles allow for an additional level of abstraction that facilitates security administration at the enterprise-level rather than at the user-level, in part, because the mapping of roles to permissions is more stable than the mapping of users to roles. The latter mapping changes each time a user is added or removed from the system, changes job functions, or is promoted. These changes are more frequent than those in the role-to-permission mapping. Role-to-permission mapping is typically driven by changes in business policies. Such business policies typically change less frequently than changes to the job functions of users. Thus, the use of role-based access control models can simplify the task of administering authorization and permission policies. There are, however, limits to this simplification. In large computing environments, the number of roles may be in the thousands. Management of these large number of roles and maintenance of user-role mappings can be arduous, expensive, and time-consuming.
More rigorous RBAC models have been introduced that employ, for example, role hierarchies where roles can inherit permissions from other roles. RBAC models that involve the imposition of restrictions on policy and access configurations also exist. One of the more common restrictions or constraints is represented by mutually exclusive roles, where the same user can be assigned to only one role among a mutually exclusive group of one or more roles. There are RBAC models that employ the notion of prerequisite roles where a user may only be assigned to role “A” if he is already assigned to role “B.”
Though these more rigorous RBAC models provide an adaptive means of enforcing security policies at the enterprise-level, the extent to which such models have allowed for reduced complexity, increased scalability, and true flexibility in the process of security administration has been limited. Defining roles and permissions sufficiently and assigning appropriate user-role associations within an enterprise with a heterogeneous IT infrastructure continues to be extremely complex and costly. The application of role-based access control models to administer user entitlements across multiple applications and computing environments remains a challenge.